Generated by 🚫 Danger

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

@jkmassel This PR has been a draft for over a month. Do we need to close it or update it to be ready for review?

@jkmassel This PR has been a draft for over a month. Do we need to close it or update it to be ready for review?

I have no idea if this is how it should be done or even a good idea – I'm hoping @wzieba or @ParaskP7 could weigh in, but I figured I'd ask after the FluxC stuff lands?

👋 @jkmassel @nbradbury and thanks for the ping!

I have no idea if this is how it should be done or even a good idea.

In terms of keeping up with the standards, this is indeed a good idea. As of AGP 8.0, the default value is true, meaning resource IDs are non-final by default. As such, it is (usually) better to use the default whenever possible.

Mostly just curious if this will work – Android Studio says it'll speed up build times

FYI:

• When set to true (non-final IDs), resource IDs can be dynamically modified at runtime.
• When set to false (final IDs), resource IDs are constants and cannot be changed at runtime.

Performance wise, non-final IDs could actually have a slight performance impact, as the values need to be looked up at runtime rather than being inlined as constants. However, this impact is generally minimal in most applications. Thus, I wouldn't worry too much about that.

PS: This became an AGP default because if has the potential for build time improvements and allowing for more flexible runtime resource loading and manipulation.

NOTE: If you proceed with this change I would recommend the following:

1. When updating an switch statements with if/else, to do it via AS and via automatic refactoring. Avoid manual refactor, just to be on the safe side. You could command + enter on that switch keyword and select Replace 'switch' with 'if'.
2. For updating the const val into val, I would recommend against that. Instead, just delete the constant and use the actual resource directly whenever needed, even if that means replacing the constant multiple times here and there, main and test source included. For example:
   • On this const val AVATAR_LEFT_OFFSET_DIMEN = R.dimen.margin_small_medium bit of code.
   • This R.dimen.margin_small_medium could be already considered as constant. No need to transform that to AVATAR_LEFT_OFFSET_DIMEN and reuse this instead, I personally think this is an overkill, and actually, in this case doesn't serve us well. Having it as a non constant var breaks the coding guideline (camel-case vs upper-case) but more importantly has the potential for this var to be updated down the line, which could result in more problems.

Hope I helped a bit! 🙏

Btw, this android.nonFinalResIds value change would also need to be update in .mobile-secrets and then this change applied via bundle exec fastlane run configure_apply on this repo.